Method of creating a computer model of the physical world

ABSTRACT

A method of executing a computer application in the context of a computer model comprising the steps of retrieving computer model data from a model server, retrieving application information from an application server, and executing said application information in the context of the model in an execution environment.

This invention relates to computer modelling of the real world. In oneaspect it is suitable for real-time modelling of locations of the worldwhereby users co-operate to populate the modelled world according totheir local knowledge.

BACKGROUND TO THE INVENTION

The computer modelling of environments is traditionally based onartificial constructs from the imagination of the environment creator.Being artificial, they require significant effort investing in theircreation, usually in the form of artistic talent and time from thedevelopment team.

Due to the large amounts of data that require processing in order tocreate such an environment, the results tend to depend on the resourcesand processing power available to the end user group and the limitationsof the supporting databus or network. This limitation will affect eitherthe extent or quality of the model environment or the cost of thehardware required to process the environment.

For example, in the case of processing power limitation, the renderingof the environment may suffer during particularly processor intensivescenes. This often results in frame rate slow down, a particularlyunwanted side-effect during, for example, a game where users areinteracting with each other requiring accurate collision detection for asatisfactory user experience. Slow down also reinforces the perceptionthat the environment is artificial. The problem occurs both at the levelof creation of the environment as a whole and at the level of creationof individual environment components such as buildings.

SUMMARY OF THE INVENTION

According to a first aspect of the present invention there is provided amethod as defined in claim 1 of the appended claims.

By providing a world server and application server, the invention thusreduces the amount of data requiring processing in order to render theenvironment. This also benefits interaction on-line between users of theartificial environment where the bandwidth of a network or internetaccess may cause problems with the user experience.

According to a further aspect of the present invention there is provideda method as defined in claim 22 of the appended claims.

By combining real world data from multiple sources, the accuracy of thephysical world model is enhanced.

According to a further aspect of the present invention there is provideda method as defined in claim 33.

By expressing component parameters using a parametric description, datais thus represented at a higher level than raw polygons. Greater powerand simplicity is afforded on a component editor executed in a componentcreation environment and the model world rendered in a client executionenvironment. Reduced data flow on the architecture supporting theenvironments and easily scalable rendering according to the resourcesavailable in the use environments allows the processing of largerdatasets at each endpoint.

According to a further aspect of the present invention there is provideda method as defined in claim 45.

By identifying underlying terrain to be cut away and melding terraininto the resulting component gap, greater fidelity is achievable whenrendering the model world for close-up viewing.

According to a further aspect of the present invention there is provideda method as defined in claim 51 of the appended claims.

According to this aspect, a distributed creation environment isprovided. Furthermore, by creating an artificial world based on thephysical world where the user experience is enhanced especially if aparticular user is familiar with the location in the environment beingviewed, users are likely to take an active interest in the accuracy ofthe rendering of a location in the artificial world if they have localknowledge of the same location in the physical world. Components aretherefore modelled based on their real life counter-parts and bear arecognisable resemblance to them enabling users to identify locations inthe model world with locations in the real world.

With all the aspects of the invention, preferable, optional, featuresare defined in the dependent claims.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described, by way of exampleonly, and with reference to the drawings in which:

FIGS. 1A-1C illustrate a general overview of a method of enabling acommunity of users to efficiently update a computer world model;

FIG. 2 illustrates client-server topology for implementing the computerworld model;

FIG. 3 shows a flow diagram of versioning

FIG. 4 shows a flow diagram of the method of user component creation;

FIG. 5 shows a flow diagram of the community voting system;

FIG. 6 shows a flow diagram of a community alert;

FIG. 7 shows a device capable of acting as a client/server;

FIG. 8 shows a road components and corresponding joins therebetween;

FIG. 9 shows a terrain tile and terrain cells;

FIG. 10 shows a road component and underlying terrain;

FIGS. 11A-11G show various steps involved in stitching a component tothe underlying terrain; and

FIG. 12 shows a flow diagram of stitching a component to the underlyingterrain.

In the figures, like elements are indicated by like reference numeralsthroughout.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The present embodiments represent the best ways known to the applicantsof putting the invention into practice. However, they are not the onlyways in which this can be achieved.

In overview, an efficient way of facilitating creation and rendering ofa computer model of the physical world requiring a reduced number ofdata transactions on the supporting hardware architecture is describedherein. Reduced data flow allows the user execution environment, forexample a high-end PC or a mobile platform to have less of an impact onmodel performance via scalable rendering according to the resourcesavailable to the user. This allows the processing of larger datasets ateach endpoint. As a result, the perceived reality by the user isenhanced by providing a more realistic model with respect to theframe-rate of display in the user execution environment. Real-time,physical-world data may also be superimposed onto the computer model tofurther enhance the user experience, and a user may utilise localknowledge to populate the model with components from the same locationin the physical world.

Referring to FIG. 1A, a general overview of a method of enabling acommunity of users to efficiently update a computer world model isillustrated in the context of an application such as a componentcreation application for use in a world model stored at a world server.At step 100, a user/client invokes from an application server, aparticular application in the context of the world server, for example acomponent creation application, and the user is verified as having therequired rights to access the data at step 102. If the required rightsare available, data is retrieved from the world server at step 104.Application data is retrieved from the application server by the userclient at step 106. The computer model world data currently viewable isrendered according to the user execution environment at step 108 in thecontext of the invoked application.

As described in more detail below, using the component creationapplication, the user is able to populate a world model component withappropriate information allowing update of the world model. For example,the user may select a building as a component and enhance the buildingwith additional visual details.

This method of updating a computer world model provides the ability,subsequently, for community members to vote upon changes made tocomponents of the computer world model made by fellow community members.The voting system is a means of handing control and moderation of thedevelopment of the computer model world to the community, based on thecomponent template provided.

In one up-front method of voting, whereby voting occurs prior to theacquisition of the new content by the user. FIG. 1B shows that if a userdesires to populate the template with a user enhanced or definedcomponent at step 110, a parametric descriptor expressing parameters ofthe component in question is acquired from the user and a community votemay be initiated at step 114 if it is determined necessary at step 112.If the community vote is a success or a vote is not required, thecomputer model world server is updated with the new component data atstep 116. This enables a single shared version of the model world commonto all users which is moderated by a voting system.

Furthermore, as an incentive to, for example, populate the computermodel world terrain with accurate representations of the real world, orto participate in relevant votes, value such as in-game economic valuemay be apportioned to transactions occurring within the computer worldmodel at step 118 and the remote user profile updated accordingly. Thisis therefore a good way to encourage population of the computer model(and hence the game world on which applications such as but not limitedto games are invoked).

In an alternative method of voting as shown in FIG. 1C, each user canbuild a unique version of the computer model world. For each componentfootprint, every user chooses the version of each component they wish topopulate their unique version of the computer model world with at step120. Every version of a component submitted by other users for thatcomponent footprint (including some auto-generated ones) may be selectedbetween. Once selected, the component appears in their unique version ofthe computer model world at step 122. Upon each instance of a userselecting a particular component, that component receives a vote at step124, hence increasing its popularity ranking. A ‘most popular’ versionof the world may therefore be determined by the system by counting thevotes for each version of a component. The popularity rating affects howthe various component versions are presented to a user for the purposeof selecting the desired version.

Furthermore, to encourage population of the model world with componentsof increasing quality, a user who has submitted a component subsequentlyselected by another user receives a reward, such as in-game economicvalue at step 126.

Additionally, a user may create their own version of a component usingthe component editor, and submit that version to the system, where itmay become available for other users to select and add to their world.

The world server stores all component versions submitted by all users,and the users choose which ones they want to see in their own uniqueversion of the computer model world. In this way, submission oferroneous or spurious components will usually result in that componentbeing ignored by other users.

In turn, the popularity rating of the component will change andinfluence whether other users subsequently select that component.

Furthermore, the system may alternatively or additionally overridecomponent selection by presenting to a user, a restricted set ofcomponents, the components of which may have been created by users of anapplication, for example a component creation application. Thisrestricted set may be selected as a result of a previous vote, or othersystem parameters, and may subsequently be subjected to a user vote asdescribed above. In this manner, the system maintains control over whichcomponents may be chosen by users, populated in their version of themodel world, and hence subjected to a vote. The component footprintsavailable for selective component population may also be restricted bythe system.

According to other aspects described in more detail below, the worldmodel can be further updated in real-time with real world data frommultiple sources and an enhanced architecture is provided allowing moreefficient and scaleable use of data.

Turning to a more detailed description of the embodiments with referenceto FIG. 2, a client-server network system 20 for implementing thecomputer model of the physical world is illustrated comprising a worldserver 200 containing computer world model data based on, for example,but not limited to, cartographic, topographic or geographic information.The term server relates to any arrangement of hardware and/or softwareand may be implemented across many physical entities, for example as asoftware server instance. The computer world model data is available forinterrogation and, with the appropriate permissions, update upon requestfrom at least one application server 210 for execution at theclient/user execution environment 230. A series of cascading caches areprovided as local data stores intermediate the servers and executionenvironment to reduce the volume of model data that must be directlyaccessible from the central world server. The application server 270executes at least one application, for example, a component creationapplication 212, executed within the context of the computer world modelstored on the world server. At least one remote user client 220 providesthe client execution environment 230 for user interaction with theapplication and model world.

The client requires only dumb terminal knowledge of how to login to theapplication server, for example acting as a web browser, with all thedata it requires passed to it for rendering according to the clientexecution environment. In order to reduce the amount of data a clientmust download, and hence the amount of data that must be handled by thesupporting architecture of FIG. 2, cascaded data cache 240 acts as alocal store of data whereby, once contained in the cache, a local clientneed not request the data again from the central world server.Furthermore, data that has been subsequently updated since loading intothe cache may be labelled such that resource server 250 overwrites thelabelled data with the new data. The local client thus need onlydownload the updated data from the local cache rather than the wholemodel from the central world server. This cache arrangement also has thebenefit of affording visibility of the updated data to other localclients, for example 222, who are operating off the same local cachecascade, irrespective of whether they are executing the sameapplication. Hence, data transfer volume is again reduced.

Multiple applications—for example, in addition to component creatinggames based on the world model—may be executed in parallel on the sameapplication server in the context of the world model. In this scenario,the application may share cache updates, information and otherapplication server resources to further economise data flow requiredbetween the world server resources and the local client and executionenvironment. Inter-application information sharing is also possibleirrespective of whether the applications are normally related.

The user execution environment resources are dependent upon the platformfrom which an application is invoked. These environments will comprisediffering capabilities with regards, but not limited to, displayresolution, display size, processing power and memory capacity. Hencethe application is sealed to the client-server platform providing areduction in data transfer across all users. For example, when theclient and server instances are on the same platform, the use ofparametric descriptors as described in more detail below enablesoptimisation to reduce processing time if the transmission bus isconsiderably faster in one scenario compared to another. This wouldreduce the risk of frame rate slow down and hence reduced playability.The rendering of the computer world template and components therein isscaleable according to the resources of the execution environment asdetected by the client. In a further example, for a PDA device, a serverinstance may render a scene and only transmit resulting imagery to theclient at a resolution or level of detail corresponding to the limitedamount of processing power available at the client. Yet further, eachuser will see their own “version” of the model world based on their ownselection of components as discussed above.

As described above, an economy model or server 260 which again can be aphysical or virtual server instance, is also provided which may beinterrogated in order to apportion economic value onto a clienttransaction and update the remote user client account. This serves toreward or provide an incentive for users to undertake certain actswithin the context of the world model, such as but not limited to,updating a model component with user data or can reflect the value ofcomponents or transactions in other applications running in relation tothe world model. A user's profile will be updated via the client with avalue according to the economy server which may equate to improvedcommunity standing, or game currency which may be spent in games or togain access to games.

As a result of the architecture described it will be seen thatdistribution of the tasks is provided at the server level providingmodularity and tailorability of the various aspects. In addition, dataefficiency is maximised at the client and by use of platform dependentscaling and cascaded caches.

FIG. 3 illustrates a method of versioning whereby a snap shot of themodel world can be taken at a definable instant in time that may be inthe past, the present or the future. Each aspect of the model world isstored as a resource, for example retrievable from a resource databaseand including a resource identifier and a resource manifest comprisingassociated data, for example, in the form of metadata, allowing theaspect to be created in the model world and including for example,rendering information, associated real world information, economic valueand so forth. At step 300, the time instant of the computer model to betaken is set on the world server. The world server calculates the modelfor that time instant if it has not been calculated previously at step302, and the version comprising a snapshot of a relevant portion of themodel world is acquired from the world server and stored in step 304 asmeta-data in the resource manifest. If desired, this snapshot may bereloaded onto the world server or local cache for use with anapplication. Versioning is capable of providing historical versions ofthe model world representing the built environment at different pointsin time, or census and migration data and can also be used forpredictive modelling such as consequences of planning permissionapplications and urban development or ‘what if’ scenarios such asdisaster planning whereby the version is developed in parallel withother versions hut based on an alternative set of subsequentdata/events.

For example, referring back to FIG. 2, different clients, for example220 and 222, although running in parallel in the context of the modelworld, may have access to a different version of the world model and canextrapolate a trend forward, or create different components. Thediffering versions of the model world are stored locally in the cascadedcache 240.

Returning to FIG. 1, user interaction in populating user-definedcomponents at step 110 onto the components template of the world serverwill now be discussed in more detail. For reasons discussed above, themore populated an area of the model world is by users, the morerealistic it will appear.

The computer model comprises a component template upon which userdefined components such as buildings, whole estates of buildings(blanket creation and paint brushing of building styles), buildings withexaggerated parametric description for stylised game play, roads,bridges, tunnels and street furniture such as street lamps etc may becreated. To allow for different degrees of artistic merit, and to keep acontrol on the amount of data flowing around the architecture eachcomponent is made up of one or more component features. The descriptionof component features is defined in terms of at least one parameterexpressable by a parameter descriptor per component feature. Thisparameter may be a visual, collision, physics engine or noise mapparameter.

FIG. 4 shows a flow diagram for creating a user defined component. Atstep 400, the component parametric description is acquired for thecomponent in question from the world server or local cache. A componenteditor is then invoked in a component creation environment at step 402followed by the parametric description of the component (step 404) toenable an accurate rendering of the component prior to editing at step406 if required. Following editing by, for example, visual or graphicalmeans, or simply entering new parameters if known, the parametricdescription of the edited component is extracted at step 408. Theparametric description is then uploaded to the world server prior topossible approval from an upfront community vote at step 410 (see FIG.5). If a new component is updated and accepted by a vote, as discussedin relation to FIG. 2, the old data is labelled at point 412 and theresource server will update the local cache accordingly at step 414. Itwill be noted that the component parameters may be derived automaticallyfrom a graphical representation of the component. The parameterdescriptors, in effect, describe the method of constructing thecomponent geometry comprising a flow chart or pipeline of steps known asnodes.

Referring to step 408 above, in the case of a building, an outline, forexample from official data sources such as Ordnance Survey, forms thebase of the building with which other parameter descriptors areassociated to create the resultant parameter description of thebuilding. For a simple form of building, a single node ‘extrude outline’would only require one parameter for the height of the extrusion. Extradetail may be added such as doors and windows. In this case, the nodes‘add door’ and ‘add window’ would comprise parameters describing thetype of the door or window, and the position to insert it in thebuilding. Higher level editing such as architectural style, type ofstone used and whether to add a tower in the case of a church allows aninexperienced component creator to form a component easily with nodescomprising high-level parameters. The individual nodes and pipeline maybe exposed to advanced users for direct editing, thus enabling a highdegree of flexibility in component creation. Different levels of editingmay be combined such as higher level editing to create a basic componentquickly, followed by lower level editing to customise and refine thecomponent. New node types may be added to extend the editing system andnode types may be re-used for creating other components in the worldother than buildings. The pipeline of nodes may be compiled directlyinto code for execution by clients that have a sufficient processingcapability. These software functions for generating buildings are morecompact than the building geometries themselves and hence require lessinformation exchange on the supporting infrastructure.

When creating a road component, a road pipeline comprising a road splinenetwork from an official data source, for example NavTeQ GPS navigationdata, provides road topology and basic properties such as number anddirection of lanes. Pipeline operations comprising specialist nodes forroads such as moving points, inserting new points, connecting roads andchanging the curvature may be applied before spline refinement takesplace.

Lane splines may be generated from the road splines to representindividual lanes of a road automatically and are fully customisable.This has the effect of breaking the generation process into smaller andmore manageable steps. Different types of lanes such as traffic andpedestrian may be defined. Further operations may be placed in the roadpipeline to additionally modify the lane spines allowing moreflexibility than going straight from a road spline to a road geometry.Following the creation of the road splines, further nodes containingparameter descriptors to generate the physical features of the road suchas the road surface, and pedestrian crossings may be used, resulting ina series of road component chunks that may be edited in the same way asa building component. For features such as lampposts, road markings andcats eyes occurring at regular intervals, a further node capable ofcreating a feature repetition is available. Features may be any size orshape. It will be seen that parametric representation of roads isutilised in the same way as for buildings hence avoiding the need forsending polygonal representations of roads or terrains to clients.

Turning briefly to FIG. 8, a resultant road component 800 may appear asrectangular chunks that exhibit triangular cracks 802 on the outside ofcorners, while on the inside, the rectangular polygons overlap 804. Atthe time of rendering, and in order to remove visible seams betweencurving road sections, the triangular crack may be filled in and acommon intersection point on the inside of the bend may be chosen toremove the overlap.

Referring to FIG. 5, a community vote in line with the method describedin relation to FIGS. 1A and 1B may be carried out in order to determinewhether a user enhanced component should be incorporated into the model.At step 500, voting is initiated by contacting clients whose users aredetermined to have an interest in the component in question. This may beusers of the application from which the component has been edited or amore general selection dependent on other parameters such as real-worldgeographical proximity. At step 502, users submit their vote followingviewing the proposed component update in their own executionenvironment. This may also include viewing a photograph of the candidatebuilding in order to compare the physical world building with the modelworld counter-part. A database submitted by users may be set up to holdphotographs for viewing on request. The application server on which theyinvoke their execution environment collects their votes at step 504 andsends it to the central world server for collation and determination ofthe voting result at step 506.

The vote result may be calculated as a strict binary type approval ordisapproval, or as a fuzzy-type vote whereby the voter submits a ratingbetween approval and disapproval on a sliding scale with the averageover all votes counted determining either approval or disapproval. Thethreshold for approval or non-approval may be set anywhere between 100%approval or 100% disapproval with the vote hence provided as a weightedvalue. The votes can then be summed or averaged according to any desiredcriterion to assess whether the proposed change is acceptable. At steps508 to 512, a successful component is updated onto the world server andlocal caches by the resource server mechanism as described above.

When a community vote in line with the method described in relation toFIGS. 1A and 1C is implemented, there may be user notification of newcomponent versions and/or more popular versions being submitted forcomponent footprints for which the user has already chosen a version, orfor which the user has submitted an edit.

As explained in relation to FIG. 1C above, the user submits a vote as aresult of selecting a version of a component from the version selection.Users may view images or photographs of components to aid in selectionof a version. These photographs may be sourced through a database ofuser-submitted photographs or through external sources, or both.

With this method of voting, instead of one definitive component versionwhich is replaced by instigating a binary vote, there may exist multipleversions each having a popularity rank based on the number of votes, andwhich can exist in a user version of the computer model world regardlessof popularity rank, acting as a permanent ongoing poll rather than anelection. Additionally, the results guide user choice rather thandictate user content. The results, however, do provide the data tocreate a definitive ‘most-popular’ version of the computer model worldbased on user-generated and user-voted content. However, this versionmay initially be invisible to the user as a coherent whole.

Collation of the results may therefore provide a ranked list or poll ofcomponent versions by popularity (the number of times a componentversion has been chosen by unique users to be added to their own versionof the computer model world). This may be used to aid user selection ofcomponent versions, reward users who submit popular component contentand create a most-popular version for internal and/or future use.

When implementing a community vote, and as explained in relation toFIGS. 1A and 1C, the system may optionally override component selectionby presenting a restricted set of components and/or component footprintsto any of the users.

Depending on the application in question, a client may or may not havevisibility of the updated component due to the suitability of the updatefor the particular application, for example, a game being executed. Thislimited distribution occurs when a model component, for example, abuilding, is appropriate for one in-game scenario but inappropriate foranother. User created component updates within the context of game play,for example, destruction of a building due to a war-type scenario mayalso require limited distribution of the component update according toin-game time relative to other application servers executing the sameapplication. It may be the case that an event has not occurred withinthe same application executed on a different application server andtherefore does not warrant a particular component being updated in thesame manner for all application servers running the same application. Afurther example of limited distribution is where different applicationsare running in parallel in the context of the model world, and theirdifferent scenarios result in some component updates being redundant,for example, it may be inappropriate for a car racing game to be set ina war zone. Hence, versioning as described above, can be implemented toallow parallel usage of the same base data and limited or prohibitedupdate distribution.

As discussed above, the parameter descriptors stored in the local cacheare rendered in real-time by the client and are scaled according to theresources available in the client execution environment. This may beinfinite scaling or a one of many selection of scaling factors. In orderto create as realistic as model environment as possible, the individualcomponents, once rendered are projected into the terrain of the modelenvironment so that they are positioned correctly with reference to thegradient of the terrain to avoid the effect of ‘floating in mid-air’ andallows higher fidelity for viewing roads close-up. Any section of acomponent that is not correctly aligned with the terrain is thenstitched at the time of display in the client execution environment inreal-time in order to create the effect of seamless integration with themodel terrain template.

The terrain within the model world is split into terrain tiles whichin-turn are split into terrain cells. FIG. 9 illustrates an arbitraryterrain tile of size 900×900 comprising terrain cells 902 forming gridsquares with cell vertices 904 and cell links 906 defined by a head andtail vertex. The size of a terrain cell is the distance between terrainheight posts which equates to the size of the smallest terrain polygonin the highest detail level terrain tile. Hence for a terrain tile of 4km², with height posts every 50 m, there are 80×80 terrain cells perterrain tile. As regards the gradient of the underlying terrain, whenrendering roads for viewing from distance, the height of the road isfound by sampling the terrain height at the road centre. The road isthen elevated by, for example, 0.5 m to prevent the edges of the roadcomponent from intersecting with the underlying terrain.

In areas of extreme gradient, the road component may intersect with theterrain. When viewing roads from a distance, it is not noticeable thatthe roads are ‘floating’ above the underlying terrain. However, forviewing roads close-up, and for increased realism, higher fidelity isavailable. In summary, to generate the road and junction componentoutlines, road nodes and shape points are processed in to a list of roadsections comprising a list of points that define sections of roadsbetween junctions. The list of basic centreline points are then fed intoa curve generation routine to produce a smooth hi-detail centreline(this may be tweaked to provide as many or as little points asrequired). Additional terrain heights are sampled if a road section isgreater than 250 m. The centreline is then widened to produce a detailedleft and right road edge.

In order to meld road and other components with the surrounding terrainat runtime, the stitching algorithm takes the outlines of model worldcomponents and cuts holes in the underlying terrain tiles in which theoutline is positioned. The space between the edges of the component andthe terrain geometry is then filled with autogenerated or melded terraingeometry. FIG. 10 illustrates a road component 1000 placed on a sectionof terrain. Terrain tiles 1002 remain untouched, tiles 1004 throughwhich the road passes require cutting and tiles 1006 are close enoughthat they may be optionally cut to provide a smoother gradient betweenthe road component and the neighbouring untouched terrain tiles 1002.The cut-out is preferably wider than the road component chunk to allowfor a realistic gradient between the road component and the underlyingterrain.

The road construction and stitching process adheres to a number of basicrules, namely;

-   -   i. Roads maintain the same height across their width,    -   Road heights are sampled at the nodes and also at additional        points along the length of the road if the road sections are        very long, for example, every 250 m,    -   iii. Roads will preferably not follow high frequency undulations        in the underlying terrain; the curve fitting algorithm will        smooth the undulations so the roads only follow major terrain        undulations, and    -   iv. Road junctions are only created where three or more roads        share the same node.

FIGS. 11A to 11G illustrate the steps of stitching a component 1100 tothe terrain in more detail. FIG. 11A shows a road component spanningfour terrain cells 1101, 1102, 1103 and 1104. From FIG. 12, at step 1200the algorithm determines which terrain tiles must be cut (in this case1101, 1102, 1103 and 1104) to accommodate the polygon outline of the newstitched component geometry and then checks for overlaps between thecomponent outlines and the terrain cell outlines within each of theterrain tiles by determining the horizontal and vertical terrain celledges within a terrain tile that are intersected and the point at whichintersection occurs at step 1201 (see also FIG. 11B, 1105). A vertex1106 is added to a cell edge where each intersection is found at step1202 and cell links being intersected are replaced by new links, 1107 tothe new vertex at step 1203 (see also FIG. 11C). Whenever a new vertexis stored, extra information such as which component polygon outlinepoints are at the head and tail of the line segment under test and whichside of the line contains the inside of the component polygon is alsodetermined and stored. At step 1204 new internal cell vertices, 1108 arecreated for each point of the component polygon outline (see also FIG.11D) and at step 1205 each new vertex is joined to an appropriate edgevertex by creating a new cell link, 1109. Step 1206 joins this vertex toany other internal vertices it the points have sequential indices in theoriginal component polygon outline (see also FIG. 11E, 1110). The abovementioned extra information stored at vertex creation time aids thisdecision. At step 1207, any cell links 1111 internal to the componentpolygon outline are removed (see also FIG. 11F) using the extrainformation and determining counting the number of splits, for examplethe links that have an even number of splits. This results in a singlecontiguous line without any splits or internal loops. Once the cut-outportion of the underlying terrain has been determined, at step 1208 thecell outline is triangulated using a standard triangulation routineresulting in a list of triangles (see also FIG. 11G) that may be addedto the custom terrain geometry for that terrain tile and passed on tothe terrain system for rendering. The joining of the triangles to theunderlying terrain may be as simple straight line or other form ofsmoothing such as a curved ‘S’ shape. Shading and shadow mapping as perthe standard terrain tiles may then be applied. Depending on thecomplexity of the underlying terrain, adjacent terrain proximal to aroad component may also have to be cut to allow for stitching in thesame manner as above.

During stitching, edge points from the outline of the feature are addedto the cell and therefore become shared edge points for the customterrain geometry. These shared edge points pull the terrain up or downin height (creating embankments and valleys) to match the position ofthe component in the model world. For the triangulation routine tofunction correctly, the component polygon outlines must not cross eachother. Outlines may, however, join with other outlines at shared edgesor vertices.

Any junctions are processed by trimming back the road ends and joiningthe left edge of one road with the right edge of its immediate neighbourat the junction hence generating a simple junction outline. This simpleoutline may be improved by adding a curve between the road ends, makingit more like a sweeping corner. Both the road sections (that have beentruncated to incorporate the junctions) and the junction outlines arethen fed into the terrain stitching algorithm and processed as above.This alters the underlying terrain and creates holes that matchprecisely where the road and junction render models will be drawn.

A further enhancement of the transition from land to water is providedby Ordnance survey or other official data whereby vector format datacontaining hard edges for land and water is used to determine which sideof the land-water transition any particular terrain pixel is placed.

Furthermore, placement data for buildings considered to be canonical mayresult in roads interpenetrating the building components. Road componentconstraints may therefore be relaxed to move them around the buildingcomponents in order to provide a more realistic model world.

A further enhancement of the world model is achievable by collectingreal-time physical world data from a plurality of sources, integratingit together and superimposing the data onto the model, for example, butnot limited to, traffic and travel information, speed camera locations,house prices, positions of the sun, moon and stars, weather informationand player position information. Abstract data, for example buildingfunction such as wine types in an off-license or liquor store andsimilar ontological data may be extracted from real world resources suchas business directories, and pushed to users (see FIG. 6 below). Thisinformation is available to clients executing applications in thecontext of the world server and rendered in the client executionenvironment. The complexity of the real-time and abstract data isscalable according to the client execution environment in the samemanner as the parametric descriptors and is presented as meta-dataattached to each resource of the model world.

Referring to FIG. 6, there is shown a flow diagram of the methodinvolved in pushing a community alert to qualifying remote users. Theworld server is able to initiate a community alert at step 600 relatingto, for example but not limited to, the geographical or post-codelocation of the user within the model world, or entry onto adistribution list dependent on location information supplied by theuser. The relevant application server responds with an acknowledgementof the community alert at step 602 and determines whether a remote usercurrently executing the application in the context of the model worldmeets the criteria for receiving the community alert at step 604.According to whether the criteria are met, the community alert is eithersent to the remote user or not sent as appropriate at steps 606 or 608.A non-limiting example of a community alert that may be pushed to arelevant, user is when a particular location is passed in the modelworld that is accurately mirroring the user's position in the realworld, an alert relevant to the same location in the real world, such aspromotional offers in retail outlets, may be pushed to the user via, forexample, the user's PDA. Extra revenue and advertising opportunities aretherefore available with this scheme of community alerts. Alternativepossibilities include news items related to the location and informationrelevant to a user's play experience within one or more of themultiplayer games executing within the context of the model world. Forexample, progress within the current game, progress within other games,friends' progress within games and significant progress of other playerswithin games can be relayed.

Referring to FIG. 7, a device capable of acting as a client/server isshown comprising main memory 702 for storage of instructions andinformation to be executed by the processor 704, such as a random accessmemory (RAM), flash memory, or other dynamic storage device, ROM 706 orother static storage device, and storage device 708 such as a magneticor optical disk, or flash memory, all coupled to a bus 710. Informationarrives and leaves the device 700 from, for example a GUI operating onthe device for direct user interaction or the preceding/next device inthe client/server architecture. The originations/destinations mayinclude a host, server, or other end station in a local network orInternet.

In the foregoing specification, the invention has been described withreference to specific embodiments thereof. It will, however, be evidentthat various modifications and changes may be made thereto withoutdeparting from the scope of the technique. The specification anddrawings are, accordingly, to be regarded in an illustrative rather thana restrictive sense.

It is to be noted that the methods as described have shown steps beingcarried out in a particular order. However, it would be clear to aperson skilled in the art that the order of the steps performed, wherethe context permits, can be varied and to that extent the ordering ofthe steps as described herein is not intended to be limiting.

It is also to be noted that where a method has been described it is alsointended that protection is also sought for a device arranged to carryout the method and where features have been claimed independently ofeach other these may be used together with other claimed features.

1. A method of executing a computer application in the context of acomputer model comprising the steps of: retrieving computer model datafrom a model server, retrieving application information from anapplication server, and executing said application information in thecontext of the model in an execution environment.
 2. The method of claim1 further comprising applying economic value to transactions occurringwithin the executed application, the method further comprising the stepsof: retrieving transaction information from the model server, retrievingtransaction information from the application server, retrievingexecution information from the execution environment, retrievingeconomic information from an economy server, apportioning economic valueto a transaction, and updating the execution environment with saideconomic value.
 3. The method of claim 1 or 2 where the computer modelis a model of the physical world, and the model server is a worldserver.
 4. The method of any preceding claim where: computer model datais modified from within an application executed in the context of themodel in the execution environment, and the modified data is populatableonto said model server.
 5. The method of any preceding claim in which aplurality of applications are executed in respective executionenvironments in the context of the computer model.
 6. The method ofclaim 5 when dependent on claim 4 wherein the modified computer modeldata is retrievable only in the context of the application execution inwhich it was modified.
 7. The method of claim 5 when dependent on claim4 wherein the modified computer model data is retrievable in the contextof a plurality of applications executed in the context of the worldmodel.
 8. The method of any of claims 4 to 7 where the modified computermodel data may be voted on by users of the application.
 9. The method ofany of claims 1 to 3 where the computer model data is lockable toprevent modification from within application execution.
 10. The methodof any preceding claim where the computer model data retrieved from themodel server is scaled according to resources available in the executionenvironment.
 11. The method of any preceding claim where the computermodel data retrieved from the model server is selected according to aunique selection from each user execution environment.
 12. The method ofany preceding claim where a plurality of versions of the computer modelare stored.
 13. The method of claim 12 wherein respective versionscorrespond to respective applications.
 14. A method as in claim 12wherein respective versions correspond to versions of the model atdifferent time instants.
 15. A method as claimed in any preceding claimfurther comprising caching a version of the model at a cache locationintermediate the model server and the execution environment.
 16. Amethod as claimed in claim 15 further comprising flagging anymodification to the version at the cache for selective upload to theexecution environment.
 17. A method as claimed in any preceding claim inwhich one or each of the model, execution and application servercomprise any one or more of a hardware, software, localised ordistributed server instance.
 18. An apparatus providing a computerapplication execution environment arranged to: retrieve computer modeldata from a world server, retrieve application information from anapplication server, and execute said application information in thecontext of the world model in the execution environment.
 19. Anapparatus comprising: a computer model server storing a computer model,further being arranged to store a plurality of versions of said model.20. A computer program comprising one or more sequences of instructionsfor implementing the steps of any of claims 1 to
 17. 21. A computerreadable medium containing the computer program of claim
 20. 22. Amethod of enhancing a model of the physical world comprising collectingreal world data from a plurality of sources, and transforming andloading said data onto a model world server to enhance the model of thephysical world with said data.
 23. The method of claim 22 where thecollected data is real-time data.
 24. The method of claim 22 or 23 wherethe data is accessed by a client of the model world server.
 25. Themethod of claim 24 where the model world server initiates a communityalert to at least one client of the server.
 26. The method of claim 25where the community alert is based on the location of the client withinthe model world.
 27. The method of claim 26 where the community alert isfurther based on a distribution list.
 28. The method of claim 25 wherethe community alert is based on the location of the client within thereal world.
 29. The method of claim 28 where the community alertcomprises information relating to the corresponding position in themodel world.
 30. A computer program comprising one or more sequences ofinstructions for implementing the steps of any of claims 22 to
 29. 31. Acomputer readable medium containing the computer program of claim 30.32. An apparatus for enhancing a model of the physical world arranged tostore said model, receive real world data from a plurality of sourcesand load said data to enhance said model.
 33. A method of creating amodel component in a computer model of the physical world, the methodcomprising displaying a plurality of component features each featurehaving a parameter expressible by a parameter descriptor, receiving auser selection of displayed, component features, and providing thecorresponding parameter descriptor to a model component creationenvironment.
 34. The method of claim 33 further comprising storing theparametric description in a component creation environment.
 35. Themethod of claim 33 or 34 where said component feature comprises a visualparameter.
 36. The method of claim 33 or 34 where said component featurecomprises a collision parameter.
 37. The method of claim 33 or 34 wheresaid component feature comprises a parameter for a physics engine or anoise map.
 38. The method of any of claims 33 to 37 further comprisingderiving said parameters from a graphical representation of the modelcomponent.
 39. The method of claim 33 further rendering parameters inreal-time for display comprising scaling the rendering according to theresources of the component creation environment.
 40. The method of claim39 further comprising projecting the component into the terrain of thecomputer model.
 41. The method of claim 40 further comprising stitchingthe projected component onto the terrain of the computer model anddisplaying the stitched component.
 42. A method of rending in a userexecution environment a computerised model world having componentsplaced therein, comprising rendering said components according to one ofthe resources of the user execution environment and the availableresolution of the components.
 43. A computer program comprising one ormore sequences of instructions for implementing the steps of any ofclaims 33 to
 42. 44. A computer readable medium containing the computerprogram of claim
 43. 45. A method of processing a three-dimensionalimage of a computer generated environment comprising a backgroundterrain and an environment component to be melded into the terraincomprising identifying a component outline, creating a componentreceiving gap having a periphery corresponding to the outline with aboundary region at least partially therearound, and melding thecomponent into the gap by generating melded terrain in the boundaryregion.
 46. A method as claimed in claim 45 in which the componentcomprises one of a road or building representation.
 47. A method asclaimed in claim 45 or 46 in which the terrain comprises a plurality ofterrain tiles, and processing is only applied to tiles in which thecomponent receiving gap is created.
 48. A method of processing athree-dimensional image of a computer generated environment comprising abackground terrain and an environment component to be inserted into theterrain comprising identifying a component outline, creating a componentreceiving gap having a periphery corresponding to the outline, insertingthe component into the gap in which the terrain comprises a plurality ofterrain tiles, wherein processing is only applied to tiles in which thecomponent receiving gap is created.
 49. A computer program comprisingone or more sequences of instructions for implementing the steps of anyof claims 45 to
 48. 50. A computer readable medium containing thecomputer program of claim
 49. 51. A method of creating a computer modelof the physical world having world components comprising: rendering acomponent template available to a plurality of remote users, andpopulating the template with data from at least one remote user.
 52. Themethod of claim 51 where said template comprises at least one ofcartographic, topographic or geographic information.
 53. The method asin claim 51 or 52 further comprising displaying a componentcorresponding to the populated template to a plurality of users in acommunity and incorporating the component into the model dependent on acommunity vote.
 54. The method as in claim 51 or 52 further comprisingdisplaying for selection a component corresponding to the populatedtemplate to a plurality of users in a community and calculating acomponent rating dependent on the number of users who select saidcomponent.
 55. The method as in any of claims 51 to 54 furthercomprising rewarding the users based on their population activity. 56.The method as in claim 55 where said rewards contribute to a status inat least one application executed in the context of the model world. 57.The method as in any of claims 51 to 56 wherein a plurality ofapplications are executed in parallel in the context of the model world.58. The method of claim 56 or 57 where said application is a game. 59.The method of claim 57 or 58 where the populated component template isdisplayed to a plurality of users of the same application as theapplication from which the user data was provided.
 60. The method ofclaim 58 where the populated component template is displayed to aplurality of users of a plurality of applications executed in thecontext of the model world.
 61. A method of creating a computer model ofthe physical world having world components comprising displaying acandidate component to a user community and incorporating the componentinto the world dependent on a community vote.
 62. A method of creating acomputer model of the physical world having world components comprisingdisplaying a candidate component to a user community and calculating acomponent rating dependent on the number of users who choose saidcomponent.
 63. The method as in claim 53 or 61 where said community voteis derived from individual voting ratings from each of a plurality ofusers.
 64. The method as in claim 61 were the voting rating comprises avalue attributed by the user between and including full approval andfull non-approval.
 65. The method of any of claims 51 to 64 where thecomponents comprise at least one of an architectural or geographicalfeature, for example a building, a road, as tree, a water feature,street furniture or a fence.
 66. A method of creating a computer modelof the physical world having world components comprising: rendering acomponent template available to a plurality of remote users wherein aplurality of games are executed in parallel in the context of the modelworld.
 67. A computer program comprising one or more sequences ofinstructions for implementing the steps of any of claims 51 to
 66. 68. Acomputer readable medium containing the computer program of claim 67.69. An apparatus comprising a remote user client server arranged toallow creation of a component for a computer model of the physicalworld, the apparatus being arranged to: display a component templatereceived from a remote server to a user, collect data from the user, andtransmit the collected data to a remote server for population of thetemplate.
 70. An apparatus comprising a server arranged to store acomputer model of the physical world having world components, theapparatus being arranged to: render a component template available to aplurality of remote users, receive data from at least one remote userserver, populate the template with data from at least one remote user,and incorporate a component according to the populated template into themodel.
 71. An apparatus comprising a server arranged to store a computermodel of the physical world having world components, the apparatus beingarranged to: render a component template available to a plurality ofremote users, receive data from at least one remote user server,populate the template with data from at least one remote user, andcalculate a component rating with data from at least one remote user.72. A method and apparatus for creating an improved computer model ofthe physical world substantially as herein described with reference toand as illustrated in any combination of the accompanying drawings.